seems generic enough that it should be in a more common util file?

I'm not sure about this one, I would move it once it's needed somewhere else. It's only here because the query param library might return null or undefined for a number, I'm not sure we have this case anywhere else.

not a strong opinion but the name isValidNumber and what it does in the fn are totally reusable in any other functions when we want to check isNaN

Let's keep it here until it's needed elsewhere

better be explicit and type the return type too

so right now i can read this line and understand it properly because I've been looking at this PR

but i worry down the line this doesn't have a very high readability

plus, both source chain id and destination chain id should be equally important conditions, so i would do this instead:

describe('when `destinationChainId` is valid and `sourceChainId` is valid', () => {
    it('should not do anything', () => {}
}
describe('when `destinationChainId` is valid and `sourceChainId` is invalid', () => {
    it('should set `sourceChainId`', () => {}
}
...

There are 2 vars with 3 possible values each (undefined/valid/invalid) so there should be 3x3 = 9 cases here
i see them all in place in this file but they should have parallel status given that the 2 vars' initial values have no dependency on each other

other than testnet, i'd also add a test for orbit <-> arb one and orbit <-> arb nova to make sure it doesn't only go to arb one and never to arb nova